A multi-tenant architecture provides each tenant with a dedicated share of a software instance and the ability (typically) to input tenant specific data for user management, tenant-specific functionality, configuration, customizations, non-functional properties, associated applications, etc. Multi-tenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants. A tenant includes a group of users who share a common access with specific privileges to a software instance providing a service. A tenant may be an organization (e.g., a company, department within a company, etc.). A tenant may have one or more roles relative to a system and/or service. For example, in the context of a customer relationship management (CRM) system or service, a tenant may be a vendor using the CRM system or service to manage information the tenant has regarding one or more customers of the vendor. As another example, in the context of Data as a Service (DAAS), one set of tenants may be vendors providing data and another set of tenants may be customers of different ones or all of the vendors' data. As another example, in the context of Platform as a Service (PAAS), one set of tenants may be third party application developers providing applications/services and another set of tenants may be customers of different ones or all of the third-party application developers. The term “user” is a generic term referring to an entity (e.g., an individual person) using a system and/or service. A user may have one or more roles relative to a system and/or service. To provide some examples, a user may be a representative (sometimes referred to as an “end user”) of a tenant (e.g., a vendor or customer), a representative (e.g., an administrator) of the company providing the system and/or service, and/or a representative (e.g., a programmer) of a third-party application developer that is creating and maintaining an application(s) on a Platform as a Service (PAAS).
When a user uses a system or a service, they may have sensitive data accessible to the service and/or system. The sensitive data can be stored or used by different components of the service and system for different purposes. For example, to enable auditing, debugging, or security compliance, log records related to events resulting from the operations of the service or system may be recorded. The log records include fields with data. The data can include sensitive data such as personal data of a user (e.g., a name of the user, a user identifier of the user, an address of the user, an email address of the user, etc.). There is a need to protect access to and retention of the sensitive data of the user to enforce data protection and privacy for this user.